Date: Wed, 6 Jan 93 04:30:03 PST 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 46 

To: packet-radio 


Packet-Radio Digest Wed, 6 Jan 93 Volume 93 : Issue 6 


Today's Topics: 
access to KA(Q tcp/ip code? 
Atari 800XL for packet ? 
AX.25 streams driver 
MFJ-1274 & TAPR 1.1.8a 
SLIP - What is 
SLIP - What is (answer) - NOS versions, 'dialer', SLIP timeout., finger 
(questions) Thanks! (2 msgs) 
TAPR Annual Meeting 
Wormhole - What is it? 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Tue, 5 Jan 1993 15:02:00 GMT 

From: newsgate.watson.ibm.com! yktnews! admin! sernews! news@uunet.uu.net 
Subject: access to KA(Q tcp/ip code? 

To: packet-radio@ucsd.edu 


In <1lia2rcINNna7@sixgun.East.Sun.COM> gilly@gilly.East.Sun.COM (Bob Gilliland SE 
Cloumbia, Md Office) writes: 

>From where on the Internet can I download Phil's, KA(Q, cuurent release of tcp/ip 
code? 

>Anonymous ftp I hope... 

> 

>Thanks for your help, 

> 

>Bob K3TCT 


The UCSD.EDU ftp server has all the latest TCP/IP code. KA9Q JUST 
posted his latest version yesterday. s930104.zip is in the 
/hamradio/packet/tcpip/ka9q directory. The other flavors of NOS are in 
their own directories in the /hamradio/packet/tcpip directory. 


73's de Jack - kf£5mg 


AX25net - kf5mg@kf5mg.d4tdfw.tx.usa.na - (817) 962-4409 
AMPRnet - kf£5mg@kf5mg.ampr.org - 44.28.0.14 
Internet - kf£5mg@vnet.ibm.com 


Date: 5 Jan 93 20:57:28 GMT 

From: dog.ee.lbl.gov!overload.1lbl.gov!agate!spool.mu.edu! yale.edu!ira.uka.de! 
Sirius.dfn.de!zam103!djukfa11! iff118@network.UCSD.EDU 

Subject: Atari 800XL for packet ? 

To: packet-radio@ucsd.edu 


As SP operates its first digipeater with links to abroad, 
I have been asked, if anybody has experience with packet 
radio on old Atari. In Poland they are still popular and 

available. 

Tank you in advance 


Piotr, DHOKPS, ex SP6 MLD 


Date: Tue, 5 Jan 1993 16:24:31 GMT 

From: usc!cs.utexas.edu! geraldo.cc.utexas.edu!portal.austin.ibm.com! 
awdprime.austin.ibm.com! inetnode.austin.ibm.com!miltonm@network.UCSD.EDU 
Subject: AX.25 streams driver 

To: packet-radio@ucsd.edu 


I seem to rember seeing a streams driver to send AX.25 packets out from 
unix systems. However, I can't seem to locate the code. The system 
will be a 386 running Interactive Unix System V version 3. 


I would apreciate any pointers. 


Thanks, 
milton 


Date: 6 Jan 93 06:00:06 GMT 
From: news-mail-gateway@ucsd.edu 


Subject: MFJ-1274 & TAPR 1.1.8a 
To: packet-radio@ucsd.edu 


Jim, 

I can't help you with the 2400 bps modem part of your problem, but I 
expect that if your 1274 was running 1.1.4, it only has 16k of RAM. 
1.1.5 and later require 32K, so you will have to upgrade. I think the 
instructions are in the 1274 manual, and the chips and instructions are 
also available from both MFJ and TAPR. The problem with the 2400 bps 
modem is entirely unrelated to the firmware, I am sure. 


Bob 


Bob Nielsen W6SWE 
ax.25: w6swe@wb7tpy.az.usa.na Internet: rnielsen@tapr.ampr.org 
amateur IP: 44.124.12.16 CIS: 71540,2364 


Date: 5 Jan 1993 16:50:21 GMT 

From: ucsd.edu! brian@network.UCSD.EDU 
Subject: SLIP - What is 

To: packet-radio@ucsd.edu 


SLIP is Serial Line IP. It's a trivial protocol for encapsulating an IP 
frame on a serial line to do cheap IP networking. KISS is the same 
thing for AX.25. Details in the docs in the hamradio/packet collection 
on UCSD.EDU. 

- Brian 


Date: Tue, 5 Jan 1993 16:18:53 GMT 

From: usc!cs.utexas.edu! geraldo.cc.utexas.edu!portal.austin.ibm.com! 
awdprime.austin.ibm.com! inetnode.austin.ibm.com!miltonm@network.UCSD.EDU 
Subject: SLIP - What is (answer) - NOS versions, 'dialer', SLIP timeout., finger 
(questions) Thanks! 

To: packet-radio@ucsd.edu 


In article <9301050143.AAQ00731@westport.trirex.com> bmehlman@trirex.COM (Ben 
Mehlman) writes: 

>I am trying to set up dial-in and dial out SLIP on my KA9Q NOS box. 

>On the dial in, I have one problem to solve, which is that I want the 
>modem to hang up on the caller if there is no activity on the port 

>for a few minutes. I don't think the NOS is equipped to do this. My 
>solution so far is to bastardize the 'dialer' code to create a 

>'watcher'. The watcher watches for data transmissions and carrier 

>status on a port. If CD stays true for XX time without any activity, 


>it (depending on how ambitious I get) drops DTR fora couple of 
>seconds or executes a hangup script. 

> 

>I was wondering: has anyone else has approached this problem, and how 
>did you solve (or fail to solve) it? 

> 


My understanding is Phil Karn has done it. He released the code in June, 
although the initial release had a "peter waiting on paul waiting on peter" 
syndrome. I don't rember the £ix. Phil also just released a new 

set of code today (yesterday?) on ucsd. Since there were several problems 
with the June release (Phil called it beta code; it was somewhere between 
alpha and beta quality), none of the other enhancers picked up the code, 
opting to stick with the known 12/21/91 release. 


> 

>Anyway, there are two things I am trying to accomplish re dialing: 

> 

> 

>1 - Keep a line up, ie dial a connection to another site and keep it 
>going, redialing automatically if the link should drop. The version 
>of 'dialer' described in my docs seems like it is written 
>specifically for this purpose. 

> 


This is the code in the 12/21/91 release and derivatives (PAOGRI, 
WG7J, etc). 


>2 - Demand dial a line, ie when I try to send a packet through that 
>port, if the connection is down it dials. If the connection should 
>be terminated (ie ma bell gives up or the other side times out), my 
>side does nothing unless another packet is sent. I was also thinking 
>another that a timeout on my end would be nice, ie set a maximum time 
>that my end will keep the connection going in the absence of traffic. 
> 


Phil has done the above. According to his last post, the latest 
code is split into up, down, and ring scripts so he can share 
his modem line with his autoswitch fax! 


>Another question: What is the difference between the current KA9Q 
>release of NOS and the version maintained by PAQGRI? 
> 


PAOGRI added several usablity features and started mailbox enhancements. 
WG7J took that code and turned it into something close to a full service 
bbs, fixing forwarding, starting finger, etc). WG7J is at least at version 
1.07b. 


>Re: finger and fingerd 

>I am having a problem with finger where I can finger the NOS box from 
>my unix box, and get the system info and a list of all ‘users' ie 
>files in /nos/cfg/finger (on my system \nos\cfg is passed to 
>net.exe). However, when I try to finger a particular user it says 
>'user not known'. I was wondering if I am doing something really 
>dumb. I also have those same users listed in my ftpusers file. 

> 

does the file have a .txt extension? 


>In the source I have, you cannot finger someone on your own machine. 
>I was wondering if there is any reason why one couldn't modify finger 
>to assume the local hostname where none is supplied. 


No, you can connect to a local socket. For it to work without a 
domain.txt for the hostname, use the loopback address (127.0.0.1). 


> 

>Thanks and 73, 
> 

> 

>Ben KB2ERP 


Your welcome, 


Milton Miller 
KB5TKF 
miltonm@inetnode.austin.ibm.com 


"These statements are made by my self and not IBM. They may or may not 
reflect the views of IBM." 


Date: Wed, 6 Jan 1993 09:13:32 GMT 

From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU 

Subject: SLIP - What is (answer) - NOS versions, 'dialer', SLIP timeout., finger 
(questions) Thanks! 

To: packet-radio@ucsd.edu 


In article <COQE2nH.uqv@austin.ibm.com> miltonm@inetnode.austin.ibm.com (Milton 
Miller) writes: 

>My understanding is Phil Karn has done it. He released the code in June, 
>although the initial release had a "peter waiting on paul waiting on peter" 
>syndrome. I don't rember the fix. Phil also just released a new 

>set of code today (yesterday?) on ucsd. Since there were several problems 
>with the June release (Phil called it beta code; it was somewhere between 


>alpha and beta quality), none of the other enhancers picked up the code, 
>opting to stick with the known 12/21/91 release. 


Actually, other than adding the "answer" script, fixing a few minor 
bugs and making some internal changes to allow dialing on media other 
than asynch lines, I really haven't done anything to the dialer code 
in quite some time. I use it constantly (right now, as a matter of 
fact) and it is pretty solid. 


>>1 - Keep a line up, ie dial a connection to another site and keep it 
>>going, redialing automatically if the link should drop. The version 
>>of ‘dialer' described in my docs seems like it is written 
>>specifically for this purpose. 

> 

>This is the code in the 12/21/91 release and derivatives (PAOGRI, 
>WG7J, etc). 


Yes, this is what the original dialer did. I ran it for years when I 
lived in New Jersey. Even though I never heard a peep from NJ Bell 

about the continuous 1 Erlang load on my second phone line, I always 
felt a little guilty about it. However, to get the free local call 

into Bellcore I had to dial into a location other than the one where I 
worked and hop back over a brain-damaged Micom terminal network. This 
was such a slow and painful process (and one I could not easily initiate 
in the other direction) that I opted to keep the line nailed up 
continuously, with the call always placed from home. 


However, now that I live in San Diego and am a local phone call away 
from Qualcomm's netblazer, I decided to do the job right and bring 
up the link only when it's needed. 


>>2 - Demand dial a line, ie when I try to send a packet through that 
>>port, if the connection is down it dials. If the connection should 
>>be terminated (ie ma bell gives up or the other side times out), my 
>>side does nothing unless another packet is sent. I was also thinking 
>>another that a timeout on my end would be nice, ie set a maximum time 
>>that my end will keep the connection going in the absence of traffic. 
> 

>Phil has done the above. According to his last post, the latest 

>code is split into up, down, and ring scripts so he can share 

>his modem line with his autoswitch fax! 


Yup, this is exactly how the code works, even down to the single try 
per packet. When you send a packet and the link is down, it is held. 
If the dial attempt succeeds, the packet (and any others that have 
arrived in the send queue) are sent. If the attempt fails, the packet 
that caused it is dropped. If there's another packet waiting in 

the queue, another attempt is immediately made. Otherwise it waits 


for another packet to arrive before it does anything. 


I do it this way to avoid any built-in "retry" timeouts in the dialer 
code. I instead rely on TCP retransmission backoffs to time each 
successive call attempt. I used to redial repeatedly from a single 
packet with my own built-in backoff, but this was much less 
satisfactory because once you got into that mode, there was no 
external way to control it. With the new way I can manually force 
continuous redialing by just starting up a repeating ping session 
across the path. 


I note that the internal hooks are now there to let you implement 
"demand dialing" of AX.25 connections if you so desire, although I 
don't see much point since an AX.25 "connection" doesn't really cost 
anything but a little RAM at each end to keep open and idle. 


>No, you can connect to a local socket. For it to work without a 
>domain.txt for the hostname, use the loopback address (127.0.0.1). 


Right. This is a convention I picked up from BSD UNIX. You can always 
talk to yourself by using IP address 127.0.0.1, regardless of any 
other addresses you may have. There's a built-in "pseudo-interface" 
called the "loopback" interface with this address. 


Phil 


Date: 6 Jan 93 05:30:04 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: TAPR Annual Meeting 

To: packet-radio@ucsd.edu 


TAPR 1993 Annual Meeting 


The Annual Meeting of Tucson Amateur Packet Radio will be held on the 
weekend of March 6th and 7th, 1993 at the Best Western Inn at the 
Airport, 7060 S. Tucson Blvd, Tucson, Arizona, adjacent to Tucson 
International Airport. 


In addition to the usual presentations of the latest and greatest 
developments in packet radio, TAPR will host a workshop on digital signal 
processing (DSP) for radio amateurs. This workshop, to be conducted by 
Jon Bloom, KE3Z, ARRL Senior Engineer, is designed to teach the 
fundamentals of digital signal processing. The target students are radio 
amateurs who understand the basics of complex (modulated) signals and are 
familiar with computer programming. The course is intended to bridge the 


gap between these two subjects, with the result that the student will be 
able to begin programming DSP applications almost immediately. The 
student's math background should include algebra and trigonometry. 


The topics covered by the presentation include: 
Discrete-time systems 
Sampling theory 
Digital filters 
Signal generation and detection 
Discrete and Fast Fourier Transforms, with applications 
Applications of DSP to Amateur Radio 
Development tools 
Review of available literature 


We are expecting to have the traditional "pizza bash" and other informal 
activities on Friday night, March 5, with the meeting all day Saturday, 

March 6 and the DSP workshop on Sunday, March 7. Registration for the 
Saturday meeting is $15.00, including a buffet luncheon. There will also be 
a $5.00 registration fee for the DSP workshop on Sunday to cover the cost of 
printed workshop materials. A steak dinner on Saturday night will be 
available for $13.95. TAPR will have a hospitality suite where you 

can gather informally, join TAPR or purchase kits and software. The meetings 
will run from 9:00 a.m. to 5:00 p.m. both days. 


A block of rooms has been reserved at the special rate of $53.00 per 
night, single or double occupancy, including full American breakfast and 
happy hour reception. For reservations, call the Inn at the Airport at 
1-800-772-3847, or in Arizona at 602-746-0271, FAX 602-889-7391 (mention 
TAPR to get this rate). 


If you are planning to attend or have a project you would like to present 
at the meeting, please call or write the TAPR office and let us know. We 
also would like to know if you are planning to attend the DSP workshop, 
so sufficient materials will be available. To have your paper included 
in the printed proceedings of the meeting, camera-ready copy should be 
submitted to TAPR no later than February 19, 1993. For further 
information, contact the TAPR office. 


Tucson Amateur Packet Radio 

P.O. Box 12925 

Tucson, AZ 85732-2925 

602-749-9479 (10 a.m. - 3 p.m., Tue-Fri) 
FAX 602-749-5636 


Bob Nielsen W6SWE 
ax.25: w6swe@wb7tpy.az.usa.na Internet: rnielsen@tapr.ampr.org 
amateur IP: 44.124.12.16 CIS: 71540,2364 


Date: 5 Jan 93 20:49:13 GMT 

From: olivea!sgigate!odin! jerber.sandiego.sgi.com! jerryb@ames.arpa 
Subject: Wormhole - What is it? 

To: packet-radio@ucsd.edu 


In article <1993Jan3.042000.11741@spatula.rent.com>, ahm@spatula.rent.com 
(Andreas Meyer) writes: 

|> In rec.radio.amateur.packet, p653663@austin.lockheed.com (p653663) 
|> writes: 

|> > Sure would appreciate some docs on the wormholes or whatever 

|> > they are called. What are they and how do you use them. 

|> 

|> I suspect a "documented wormhole" would be called a "gateway". :-) 
|> 

|> Andy 

[use 

|> Andreas Meyer, N2FYE ahm@spatula.rent.com "Been there. Did 
|> that." 


Now I know nothing about wormholes except for what was in a recent 
newspaper article that discussed them briefly. 


It's a VERY theoretical/hypothetical method of travel through space that 
allows very rapid/instantaneous travel via these so-called 'wormholes' to 
distant (light years of distance) places. It's said that this method, if it 
can be figured out enough to use, would allow some forms of spacetravel to 
be almost instananeous. 


This theory is beyond my understanding, but they claim it has serious 
scientific validity. 


Please no flames... I'm no trekky, and have no belief in the above one way 
or another, just relaying a tiny bit of what the newspaper article said. 


Bottom line? Don't look for a wormhole to be available anywhere soon. 


Jerry Bransford 
Silicon Graphics 
(619) 546-0409 


Date: Tue, 5 Jan 1993 20:00:08 GMT 
From: das.wang.com!wang!tegra!vail@uunet.uu.net 


To: packet-radio@ucsd.edu 


References <1993Jan2.184109.13079@mnemosyne.cs.du.edu>, 
<eNTRwB1iw164w@ham.almanac.bc.ca>, <1993Jan4.144520.19597@ultb.isc.rit.edu> 
Subject : Re: Who do repeater coordinators represent? 


In article <1993Jan4.144520.19597@ultb.isc.rit.edu> cep4478@ultb.isc.rit.edu (C.E. 
Piggott ) writes: 


In article <eNTRwB1w1l64w@ham.almanac.bc.ca> emd@ham.almanac.bc.ca writes: 
>and that in many areas, all available repeater frequencies were assigned 
>BEFORE Packet became popular. There are several possible solutions here. 
>1. Persuade some local group to "give-up" a voice repeater frequency so 
> you can put up a packet repeater. 


Statements like "I heard packet works better through a repeater" concern 
me (not that you said that - I've just heard it before). One of the 
potential strengths of packet is as a distributed, redundant system. 
Adding a repeater greatly reduces collisions, but at a significant 
expense: 


I don't understand why you think these are problems: 


- the repeater is a single point-of-failure, and 
many people will not be able to or know 
how to operate without it when the repeater 
dies 


Making a better system will encourage stupidity? 


- repeater coverage rarely stays localized. After 
a while, a better antenna, more power, etc. 
and you wind up with a wide-coverage packet 
repeater that is jammed up. 


Making a useful system will make people want to use it? 


I don't see either of your points as being problems. In fact if it 
were to become a problem then it just points out the need for *morex 
digital repeaters. 


Getting back to the original topic we can discuss the problems of 
getting coordination since the repeater coordinators consider it 
packet and not eligible for the same protection as their repeaters. 


| | Johnathan Vail vail@tegra.com (508) 663-7435 
|Tegra| jv@nidxg.ampr.org N1IDXG@448.625- (WorldNet) 
s-55 MEMBER: League for Programming Freedom (league@prep.ai.mit.edu) 


Date: 5 Jan 1993 22:03:14 GMT 
From: usc!cs.utexas.edu!tamsun.tamu.edu!cs.tamu.edu! kurt@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <eNTRwB1w164w@ham.almanac.bc.ca>, 
<1993Jan4.144520.19597@ultb.isc.rit.edu>, <COECw9.or@tegra.com> 
Subject : Re: Who do repeater coordinators represent? 


In article <COECw9.or@tegra.com>, vail@tegra.com (Johnathan Vail) writes: 
|> 

|> I don't see either of your points as being problems. In fact if it 

|> were to become a problem then it just points out the need for *xmorex 
|> digital repeaters. 


Amen! 


|> Getting back to the original topic we can discuss the problems of 
|> getting coordination since the repeater coordinators consider it 
|> packet and not eligible for the same protection as their repeaters. 


True. Coordinators have the attitude "if it buzzes, we don't do it." 
However, aS a wise person observed, "Packet people don't know sx*t about 
radios; Radio people don't know sxxt about packet." In the general case, 
regrettably true. Packet folks aren't experienced enough to deal with 
coordination lore. AND they don't consider full-duplex regenerators 

(aka packet repeaters) as repeaters, because some of the bits get changed. 
They really don't but that's a nit. I maintain that there is a signal 
that is being received, and the information is being retransmitted in 
real-time. THAT's a repeater, and coordinators should be able to 
coordinate those, because it's the case that the frequencies need to be 
(Oh Gawd, they'll pounce on this...) "protected" by coordination. 

Simplex (standard digipeating) packet systems should NOT be coordinated, 
at least in terms of spectrum. Packet groups, if they are stupid enough 
to get into it, should coordinate that. There's coordination, then there's 
coordination. 


In the pure sense, repeater coordinators should not represent ANYBODY. 
They are a central, neutral, organ that should be used to COORDINATE 
the usage of spectrum, under the "accepted standards". The group that 


decides the "accepted standards" consists of the folks that represent 
whatever factions that obtain. Rather like the Geneva Convention, I'd 
venture. 


Vox Populi, Vox Dei - Latin for "How did we get into THIS mess?" 
..-Name that author... 


Kurt Freiberger, wb5bbw kurt@cs.tamu.edu 409/847-8607 fax:409/847-8578 
Dept. of Computer Science, Texas A&M University DoD #264: BMW R80/7 pilot 
"We preserve our freedom using three boxes: ballot, jury, and cartridge." 

xxx Not an official document of Texas A&M University xxx 


Date: Tue, 5 Jan 1993 19:28:20 GMT 
From: qualcom.qualcomm.com!servo.qualcomm.com! karn@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <1993Jan4.170301.16175@sernews.raleigh.ibm.com>, <CODC8G.CF5@zero.com>, 
<licen4INN2dg@newz.ens.tek.com> 
Subject : Re: Wormhole - What is it? 


The term "wormhole" as applied to amateur packet radio (it was 
obviously borrowed from science fiction) refers to a link in an 
amateur network that uses non-amateur facilities such as a commercial 
satellite link, leased line, the Internet, etc. 


A wormhole usually encapsulates the amateur packet protocol within 

those of the non-ham network in such a way that the non-ham network's 
internal details are hidden from the ham user. The two amateur nodes 

on the ends of the wormholes appear to be immediate neighbors, even 
though there may be much distance and a very complex (non ham) network 
between them. Hence the apt allusion to the sci-fi concept of a wormhole. 


The allusion is even more apt when you consider that both types of 
wormholes are usually provided by fantastically advanced beings with 
vastly superior technologies who have a difficult time understanding 
the motives and makeup of the primitive corporeal beings that use 
them. :-) 


Date: 5 Jan 1993 16:58:11 GMT 


From: news.tek.com!cascade.ens.tek.com! ronk@uunet.uu.net 
To: packet-radio@ucsd.edu 


References <1993Jan3.042000.11741@spatula.rent.com>, 
<1993Jan4.170301.16175@sernews.raleigh.ibm.com>, <CODC8G.CF5@zero.com> 
Reply-To : Ron.C.Kirkpatrick@tek.com 

Subject : Re: Wormhole - What is it? 


In article <CODC8G.CF5@zero.com>, steve@zero.com (Steve Urich) writes: 

|> In <1993Jan4.170301.16175@sernews.raleigh.ibm.com>, JGRASS@VNET.IBM.COM writes: 
[> Peal 

|> > A wormhole is a long distance link between two stations using the 

|> >same protocol. A gateway converts one protocol to another. A wormhole 

|> I'd say, I seen one in action today on the new startrek series 

|> Deep Space 9. It gets you right into the Gamma quadrant in 

|> about 30 secs pretty good eh :-). 


Today??? I don't get to see DS9 until Thursday! (I must be caught in a time 
vortex.) 


Ron Kirkpatrick 
Tektronix, Inc 
News Administrator 
503-627-6707 


Date: Wed, 6 Jan 1993 09:32:18 GMT 
From: qualcom.qualcomm.com!servo.qualcomm.com! karn@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <1993Jan2.184109.13079@mnemosyne.cs.du.edu>, 
<eNTRwBiw164w@ham.almanac.bc.ca>, <1993Jan4.144520.19597@ultb.isc.rit.edu> 
Subject : Re: Who do repeater coordinators represent? 


In article <1993Jan4.144520.19597@ultb.isc.rit.edu> cep4478@ultb.isc.rit.edu (C.E. 
Piggott ) writes: 
>Statements like "I heard packet works better through a repeater" concern 
>me (not that you said that - I've just heard it before). One of the 
>potential strengths of packet is as a distributed, redundant system. 
>Adding a repeater greatly reduces collisions, but at a significant 
>expense: 
> 
- the repeater is a single point-of-failure, and 

many people will not be able to or know 

how to operate without it when the repeater 

dies 


VV VV 


- repeater coverage rarely stays localized. After 
a while, a better antenna, more power, etc. 
and you wind up with a wide-coverage packet 
repeater that is jammed up. 


VVV MV 


Deja vu warning... 


I happen to agree with this. Using repeaters to reduce collisions 
xdoesx involve a significant opportunity cost. Unfortunately, the 
alternative techniques to "do it right" are still not yet known in the 
amateur service. These include: 


1. Spread spectrum, which creates a channel that degrades more 
gracefully with multiple simultaneous transmitters than does a 
narrowband channel. 


2. Strong forward error correction coding. By decreasing the required 
signal-to-noise(interference) ratio, this enhances the ability of 
spread spectrum to tolerate multiple simultaneous transmitters ona 
channel. And by reducing the necessary transmitter power to sustain a 
link, it also reduces interference to other receivers. 


3. Automatic transmitter power control so you never use more power 
than is actually necessary to reach a particular node. 


4. Automatic routing algorithms with link metrics based on 
power/interference estimates so that paths are chosen on the basis of 
their minimum impact on overall system capacity. I.e., you would 
choose a path of many closely spaced nodes over a few widely spaced 
nodes because the much lower power required at each hop would more 
than make up for the increased number of hops. 


Phil 


Date: Tue, 5 Jan 1993 15:09:58 GMT 
From: swrinde!emory!kd4nc!ke4zv!gary@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <1993Jan2.184109.13079@mnemosyne.cs.du.edu>, 
<eNTRwB1wl64w@ham.almanac.bc.ca>, <1993Jan4.144520.19597@ultb.isc.rit.edu> 
Reply-To : gary@ke4zv.UUCP (Gary Coffman) 

Subject : Packet Repeaters was(Re: Who do repeater coordinators represent?) 


In article <1993Jan4.144520.19597@ultb.isc.rit.edu> cep4478@ultb.isc.rit.edu (C.E. 
Piggott ) writes: 
> 


>Statements like "I heard packet works better through a repeater" concern 
>me (not that you said that - I've just heard it before). One of the 
>potential strengths of packet is as a distributed, redundant system. 
>Adding a repeater greatly reduces collisions, but at a significant 
>expense: 


- the repeater is a single point-of-failure, and 
many people will not be able to or know 
how to operate without it when the repeater 
dies 


- repeater coverage rarely stays localized. After 
a while, a better antenna, more power, etc. 
and you wind up with a wide-coverage packet 
repeater that is jammed up. 


VV VV VV VV VM 


That's true, but it's also true that most packet groups are sparse 

enough that high site nodes are required xanywayx to maintain connectivity, 

and they also serve as a single point failure xand* as a magnet for congestion. 
Therefore these arguments apply equally to them. The fact is that a repeater 
just works much better than a high site simplex node for packet. 


If you stick with just home stations and multi-hop links, then you're 
generating even more congestion since each packet is transmitted multiple 
times. Home sites are unfortunately not engineered to be non-interfering 
cells. And one home station shutting down can fragment the network if it 
is the only link between two subnets. That's very common in rough terrain 
with sparse networks. The channel delay of multiple hop transmissions also 
turns a slow service into an infuriatingly slower service. 


Repeaters for packet should best be thought of as large, controlled 
coverage cells. Linked by a high speed backbone, they offer high 
thruput while minimizing the interference common to simplex networks. 


Gary 

Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory !kd4nc! ke4zv! gary 
emory!ke4zv! gary@gatech.edu 
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